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(54) Dynamic classes of service for an International cryptography framework 



(57) An international ayptography ffamework (ICF) 
aliom manufacturers to comply with varying national 
laws govemtng the distrSxition of cryptograf^ capabil- 
ities. The invention is concerned primarily witfi the appli- 
catiai certif icatkwi aspects of the framework where an 
application (29) that requests cryptographk: services 
from the ICF sen/ice elments is identified through 
some form of certificate (28) to protect agairet the mis- 
use of a granted level of ayptography The levels of 
ayptography granted are d^atoed via security policies 
arxi expressed as classes of service (26). A aypto* 
graphc ur^t (14), one of the ICF core elements, can be 
used to build several certifk:ation schemes for applica- 
tion otjjects. The invention provides various methods 
that d^ermine the strength of binding l>etween an appli- 
cation code image and the issued certif icates within the 
context of the fCF elements. A key element Kwith regard 
to the exerdse of a ayptographic function concerns the 
special requrements for the trust relation that an 
authority (22) specifies fa the cryptographic unit (14). 
Any function exercised by the ayptographic unit (14) 
must t>e oontroflatile by the associated class of service 
which represents the security po«cy. Touchpointing, 
both in the application and the f innware elements inside 
the cryptographic unit (14), plays a key role in exercising 
control over the functioning of these modules. Another 
fundamental requirement of the ICF architecture is that 
the application is assured of the integrity of the crypto- 
graphic unit (14) from which it is receiving sendees. 
Thus, the invention also provides methods that allow a 
determination of whether or not the cryptographic unit 



(1 4) has been replaced or tanpered with. 
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Description 

BACKGRQUWp THF ifJVCMTinM 
5 TECHNICAL HELD 

The invention relates to cryptography. More particularly, the invention relates to dynamic classes of senrice for use 
win an international cryptograph/ framework. 

»o OESCRiPTION OF THE PRIOR ART 

CusfbiTiere" of large are typically multinational corporations that want to purchase ««erprlse 

wide oomiwter based solutions; The distraxjled nature of such organizations requires th&n to i«e puUic iiiternafional 
MmmunicatKws senrices to transport data throughout th^^ 

of their communications and seek to use modern end-to-end cryptographic facilities to assure privacy and data 
integrity. 

The use of cryptography in communications is governed by national policy and unfortunately, national policies differ 
wrift r^)ect to such usa Each national policy is developed independently, generaUy with a more national emphasis 
If^'^Il^Ijr'^ considerations. There are standards grotpG that are seeking to devetop a common crypto- 
OraphicaHjonth^ suitable for intemationai cryptography. However, the issue of international cryptographic standards is 
iwt a technical problem, but rather it is a political issue that has national sovereignty at its heart As such, it is not real- 
istic to ejqject the different national cryptography policies to come into alignment by a technical standaidization process 
^ u!f "^'^ interests in cryptography is a particular concern of companies that manufacture open-stand- 

ards-based inlomiation technology products for a worWwide market. The market expects these products to be secure. 
I^"**!^ -!^® consumers of these products are themselves multinafionai and took to the manufactureis to help 
mem resolve the mtemattonal cryptography issues inhibiting their worfdwide information technotogy development. The 
pere^nM of urvesolved differences and export restrictions in national cryptography polk:ies has an adverse inpact 
on mterrational maritet growtti for secure op«i conputing products. Thus, ttwrouid be helpful to provide an intemationai 
framewjrit that provkJes global information technology producis featuring common security elements, while respecting 
so tiw independent devetopment of national cryptography polKies. 

Nations have reasons for adopting policies that govern cryptography. Often these reasons have to do with law 
enforcement and n^onal security issues. WHhin each country fliere can be debates between flie government and «ie 
people as to the nghtness and acceptability of these policies. Rattier than engage in these debates or try to forecast 
tiieir outcome, rt is more practical to accept the sovereign right of each nation to establish an independent policy qov- 
35 eming cryptography in communication. 

l^ides governing national cryptography not only express the w8l of the people and government but also embrace 
certain tectinotogies ttial facilitate cryptography. Technotogy choice is certainly one area where standardization can 
pbya rdft However, as indicated eariier this is not soieV a technical problem, such that selection of common crypto- 
graphic techndoQies alone can not resolve the national polky cfifferences. Consequently, it wouto be useful to provide 
a common accepted cryptography frameworit. vrtierein independent technotogy and policy choices can be made in a 
va/ that Still enables international cryptographic oomnuinications consistent with these policies 

A fouripart techiKifogy frameworit that supports international cryptography, whfch includes a national flag card, a 
w>ptograptwunrt.ahost system. andanetwort<securityservw R.MercWing. International 

Cn^^hyFramework. m a copending U.S. patent application serial no 08/401.588. which was filed on 8 March 
/kTcX;^** elements have a fundamentally hierarchical relationship. The National Rag Card 

(NFC) IS insfa^led into tfie Cryptijgraphic Unit (CU) which, in turn, is instelled into a Host System (HS). Cryptographic 
f unrtwns on Uie Ho^System cannot be executed without a Cryptographto Unit which itself requires the presence of a 
wiM National Rag Card before its services are avaflaUe. The fourth sennce element a Networit Security Server 
(NSS). can provide a range of different security servfces including verification of the other three service elements. 

The ntemational cryptography framewortt (ICF) snjports the design, implementation, and operational elements of 
any and afl national policies, while unifying the design, devetopment and operation of independent national security 
ponaes. The framework thus gives sfandard form to the sennce elements of national security polkjes where such senr- 
ice elements include such things as hardware fomi factors, communication protocols, and on-line and off-line data def- 
initions. 

fiscal to the implementation of the framewort* is the provision of a fundamental tec^^ produc- 
tion of the vanous service elements. Whil various implementations of til service elements are within the skill of those 
v«sed in the rdevant art there exists a need for specific inprovements to the state of the art if the full potential of the 
frameworidstoberealized. Fbr example, it would be advantageous toprovWeasecuremechanismfor establishing var- 
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ious classes of service and methods In connecbon with the use of ayptography and other features of the framework. 
SUMMARY OF THg IWVFNTinM 

5 The international cryptography framework allows manuiacturers to comply with varying national laws governing the 
distritMition of cryptographic capabilities. In particular, such a framework makes it possible to ship worldwide crypto- 
graphic capabilities In all types of information processing devices (e.^. printers, palm-tops). Within the framework, a 
cryptographic unit contains several cryptographic methods (e.^. DES. RSA. MD5), 

The invention herein is concerned primarily with the applicatfon certification aspects of the frameworic It is a fun- 
10 damental requirement of ICF that an a«)lication which requests cryptographic services from the ICF service elements 
^™ ^ certif irate to protect against the misuse of a granted level of cryptography. The levels 
of cryptography granted are described via security policies and expressed as classes of service. 

Theayptographicunit. one of the ICFoore elements; can be used to buiWse^eral certifira^ 
cation objects. The invention provides various methods that determine the strength of binding between an applicatkm 
IS code image and the issued certificates within the context of the ICF elements. A key element with re^ to the exercise 
of a cryptographk; function concerns the special rec^irements for the trust relation that an authority specifies for the 
cryptographic unit. For example, any function exercised by the cryptographic unit must be controllable by the associated 
class of service whfoh represents the security policy. The toucf^inting concept discussed in this document for both the 
application and the firmware elements inside the cryptographic unit plays a toy role in exerdsing control over the lunc- 
20 tioning Of these modules. 

Another fundamental requirement of the ICF arcftitecture is that the applfoation is assured of the integrity of the 
cryptographic unit from which it Is rec^ng services. Thus, the invention also provides methods that allow a determi- 
nation of whether or not the ayptographic unit has been replaced or tanpered with. 

^ BRIEF DESCRIPTiON OF THg DRAVy iM^g 

Rg. 1 is a block cfiagiam of an fnternatfonal cryptography framework, Including a national flag card, a ayptographfo 
unit, a fiost system, and a network security server; 
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Rg. 2 is a block schematic diagram that introduces additional management elements of the ICF according to the 
invention; 

Fig. 3 is a block schematic fllustration of the ICF and certrication requirements accoixiing to the invention: 

35 F^. 4 is a block diagram showing the relationship of the administration elements of the ICF. /.a ADA and SDA 
according to the inventfon; 

Fig. 5 is an ilkistration of the dass of servfee structure according to the invention: 

« FtQ, 6 is a block schematic diagram that illustrates the COS level concept according to the invention: 

Rg. 7 is a block schematic diagram that illustrates key elements in the admir^stration process according to the 
invention: 

4$ Rg. 8 is a software archHecture overview of the ICF software environment accoiding to the invention: 

Rg. 9 illustrates the methods available to pass certificates to the service provider responsible for executing the 
requested functfons aoooiding to the invention; 

so Fig. 10 is a ttock schematic diagram that illustrates an exemplary architecture of the CU according to the invention; 

Rg. 11 is a block schematic diagram of the cryptographic unit fimware according to the invention: 

Rg. 12 is a block schematic diagram that illustrates the concept of a virtual CPU accorcfing to the invention; 
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Rg. 13 is a btock schematic diagram that shows the software component certiffcation process during the installa- 
tion stage according to the invention; 
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stage accoiaing to the inventran; 

Rg. 15 illustrates software levd touct^joints accoiding to the invention: 
Fig. 16 illustrates instruction level touchpoints accxwding to the inveition; 
Rg. 1 7 is a block schematic diagram showing the manufacturing stage accoixfing to the invention; 
Rg. 18 is a block schematic diagram showing the installation stage accodihg to the. invention: 
^ ' ? schemafc diajpam of the executidn stage accoiding to the invention; 

Fm. 20 illustrates the princ^ of Oasses of Sen^. touchpoints. and envelopes aoconlrng lo the invention; 
^ 21 illustrates the memory hierarchy with respect to the software touchpoint resolution acoorefing to the inven- 

has stOKlured instruction level touchpoints installed acootding to the invention: and 

Sfai^^S'trs:^^"^"''^""^^ 

« PETAILEP DESCRIPTIOM OF TWF Ifiy^ft^ 

mak^SSES? ^ '"^^ segment, political climate, and^or message function. This 

TOfcre It diffeuB 10 assign one unrtbrni policy across all industries for all time. Consequently, the flexibility of a cryotoo- 

^X'^*'::^r^^'"'''"^«*«"=^- P°«<=y- feveryatlractive.T3,e^SSnto^ne2SeS 

r7(^^!^ ^i^^*^**"*^ ^ isabtock^aammoflhe international crypfographyframewo* 
Sl i^^Z^rT^ "^^ """"^ *° as a "poficy canr (PC) and asT^^oTz. a 

Sl^Ilt;«JS^2^''- '"^^"^^^^ 18. Hshould be appreciated thTvSciisrttS^F 
"«ybeo5nibinedwrth.n a common environment. e.g. thecryptographic unit and polfcy card may residewithin 
^<Te^^ir^- "^'P^'* PoOcy ca«l. and host system may a 4<e^S2S 

^1^*" " "^'"^ ^ Cryptographic Unit (CU). This element of ICF supports an 

the CU.Th^eapplicatKMTS are bound tightly to the CU during runtime wimaiwuseor 

mJ^2SL"r«j!25J^ul*^'^'^*^"^ These functions are dor- 

Zl^^^H by a f»C. The cryptographic functions included in the CU are deter- 

tei J™^.2fi «2 or unrt that contains cryptography usage policy SpecfficaHy this element of ICF eon- 

te»«^.«ne^ govern thej«e of cryptogram 

dement IS responsible «3rr«poncfing to the CusheartoeatchaBer^e. «««i«e.oiis 

»e Inndware cryptographic functions (see Wemba et al. Cryptographic Unit Toucly Point Logic US Patent 
'^fl^ 1 996). must be inpleme^ed for a physical pZc^A^^ 

VPC scenana poficy dtstrOxition involves the network security server -m «». «. 

senJ^SS ^rJ'SL'^* ^ P^^^ "^"^^ network security 

^S^irf?».2^-^ ^^-J^f « ^^'^s include policy enhancements. poGcy distribution, unit verification. 
acSusfcnents to authorizations, and key management services. 

ICF Management Ffameworfc Peripheral to the core elements of ICF are the manufacturers of the cryptographic 
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equipment and the domain authoritfes which inplement the policy definition and enforcenient through the framewoik. 
Fig. 2 is a block schematic diagram that introduces these additional management elements of the ICR 

There are four basic elements within the administration framework These are the Security Domain Authority 20. 
the Application Domain Authority 22. the Host System Elements 16, and the Network Security Server 18. 
5 The toitowing definitions apply with regard to the discussion herein; 

Manufacturer. The manufacturer is the actual producer of cryptographfc equipnfwnt The manufacturer shares infor- 
mation with the security domain authority about each lot of Cus manufactured. 

Security Domain Authority. The security domain authority ( SDA) is the institution which defines the security policies 
governing the domain. Security policies are presented to the other framewori< elements via classes of services (COS). 
10 Knowledge of manufacturing information allows the aeation of classes of services targeted to a deterministic set of 
Cus. 

Applicatiofii Domain Authority, The Application Domain Authority (ADfi) acts as tfie authority tfiat creates certifi- 
cates for the application. The certificate contains the granted classes of service to tile application as they were granted 
by the SDA. 

IS Networi^ Security Server. The Network Security Server (NSS) acts as the trusted on-line autiiorfty tiiat manages 
policy activation fbr a given CU. 

Host System / Application / CU. The host system on which the applications are installed and on which the CU serv- 
ices are used form tiie execution elements to be controlled by tfie framework. 

The two domain autiwities are shown at the top of Fig. 2. The security domain authority (SDA) is responsft^le for 
20 granting a set of classes of service 26 to the application domain authority. The SDA is also responsible for issuing policy 
cante whwh contain the COS wifbrmation and the touchpoint data fbr the CU. The SDA manufactures this information 
upon request from tfie site which installs the CU into a host system. 

The application domain authority (ADA) receives the COS elements granted by tiie SDA. It has the responsibility of 
issuing appCcation certificates 28 to applications 29 tiiat belong to its domain. An appik»tion certificate contains an 
25 appication ID and the COS granted the ADA. 

Applk:ations receive a certificate from the ADA, which must be presented to the CU to receive the desired COS 
level. The CU, upon receiving tiie request uses the certificate to detenrwne whether tfie applfcation has the right to 
access the requested cryptogaphic function. If the COS requested via the apj^ication certificate matches tiie COS 
granted by the SDA to the ADA. and stored in the poficy card, the request is handled, otiierwise it is not handled. 
30 The touchpoint data are tfie information that is stored on tiie policy card 12, and which enable the ayptographic 
hardware fbr tiie defined classes of service. Periodically, tiiis information is recomputed by the CU and validated by tfie 
policy card. Any mismatch causes tiie cryptographic capability of tfie CU to decay. 

The network security server 18 (NSS) acts as an online instrument for policy negob'ation and changes to the policy 
information stored on tfie polfcy card. Adding a class of sen^ice to the set of services normally requires the issuing of a 
35 new policy card containing the changed information. Alternatively, the NSS performs the update of tiie policy card on 
behalf of tfie SDA. 

The NSS also plays the role of distribution of virtual policy caitfe (VPC). VPC implementations must contact tfie 
NSS at defined points. e,g. system startup to retrieve the COS Information. There are COS attributes which def ffie 
exactfy when a CU must contact tfie NSS. 
^ Basic ICF Architecture Assumptions. The ICF architecture rests on a few very basic assumptions about tiie core 
elements. They are as follows: 

Certification. All software elements, whetiier tfiey are firmware components installed inside tiie CU or applications 
using tfie sendees exported by tfie CU. are guarded by a certificate. Any operation, eg. the downloading of fimiware 
modules or an application for a certain level of sen«ce. involves the validation of this certificate. 
4S Thus, one technique that is expfofted to advantage by tiie invention to enhance security witfiin tfie frameworii is to 
require certification at various points. The use of certificates in general is known. See, fbr example ITU-T Recommen- 
dation X.509(i993). 

The X509(93) certif foate fbrmat is as fdfows: 

so ■ 
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Certificate = SIGNED SEQUENCE { 
version [0] version DEFAULT v1 , 
serialNumber CertificateserialNumber, 
signature Algorithmldentifier. 
issuer Name, 
validity Validity, 
subject Name. 
subjectPubliclnfo SubjectPublicKeylnfo. 
issuerUniqueld [IJIMPLICIT BIT STRING OPTIONAL, 
subjectUniqueld [ajIMPLICIT BIT STRING OPTIONAL 



Two variations in the existing X509{33) specifications are of interest in connection with the invention: 

• The effc»1 to drive the unique identif iens across domains based on the Weiarchical nature of the authorities inter- 
connectioa for example in the process of vafidating a certfflcate or a policy as refen-ed in Constructing X509(93) 
certificate Uniqueldentifiers from specific certification system semantks, Dept of Conputer Aiohrtecture - Univer- 
sitat of Poiitectnk:a de Cataiunya Barcelona (Oct. 94) (also an EWOS reference EWOS/EGSEC/94/183): and 
mrfdr^ Draft for extensbns to X5(mSQ/IEC 9594-S certifk:ate definttions (Jul 94) (also an EWOS reference 
EW0S«GSEC/94/168). Policy IDs are registered l>y community int«iest groups, such as NSA and SCSSI; <x by 
private orgamzafions. such as the Software Piisfisher^ Assodatfon or Microsoft Corp, of Redmond. Washington . 

• The couplendentified policies and authority constraints, as referred to in Wo/idng Draft for extensions to 
X^/iSO/lEC 9594-8 certificate definitions (Jul 94) (also an EWOS reference EWOS/EGSEC^ISS) are well 
suited for aoss<ertifcation of compata)le policies between governments. For exairple the local domaui poik:ies 
that the herein descriied dass of senrtce is expressly recogrized as siworting. once mentioned in the extension 
field, m^ w m^ not be usable with other policies as weB. and therefore facilitates the recognition of conpatible 
polides. An application of this aspect of a certificate is the Internet policy certif wation authority, which could cross- 
certify a private organization policy using this schema 

Extensfons for the policy or certification system semantics can be found in the UniqueW field suggested by Con- 
stnjcting X509(93) certificate Unk^fdentiT^rs from spedft certification system seman/te. Dept of Conputer Archi- 
tecture - Universitat of Fdlitectnica de Cataiunya Barc^ia (Oct. 94) (also an EWOS reference 
EWOS^GSEC/94/183)- The Certificate Extension fi^ called pofides field or authorityconstraints field as d^ined in 
Working Draft br extensbns to X509/IS0/IEC 9594-6 certificate definitions (Jul 94) (also an EWOS referaice 
EWOS/EGSEC/94/168) would satisfy the second requirement 

Providing Cryptographic Functions. A system which implements the physical policy caid scheme, reqtares the CU 
to implement hardware fouchpoints. The CU does not provide the HS with any cryptographic factions without entering 
into and maintairung contact with a PC. A system which implOTents the virtual PC scheme requires the presence of an 
NSS. There must be at least an initfel cwtact between the NSS and CU to distribute the VPQ The CU may also be 
required to a»Ttact the NSS on a.regutar basis that is determined by COS attributes which describe the policy fife cyde. 

S^jaration. Under no circumstances can user data that is processed within the C U be accessed by the policy ele- 
ments, regardless of whether the policy card is a physical or the virtual policy card. Ukewise, und«' no circumstances 
should the host system have access to the policy elements related data such as touchpoint data infomiation. 

Control, The CU or CUs controlled by a given PC or VPC is deterministic, i.e. every event act, and decision of the 
CU is the inevitable consequence of antecectents that are ind^endent of the PC. 

ICF Basic Trust Requirements. Fig. 3 is a block schematic illustration of the ICF and certification requirements. The 
ICF envirormient depends on a method of validating that an application 29 rightfully executes a certain level of cryptog- 



6 



1 



EP0 843249A1 

raphy as it was granted by the application domain authority in the form of a certificate oontainir^ the valid class of serv- 
ices. A tight binding of the application to this certificate is therefore an important element of the ICF. The process of 
establishing this trust Is refenred to as application certification througfput thte document. 

Application certification deserves two major elements of establishing trust t>etween the application 29 and the 
s cryptographic unit 14. 

The first part concerns the process of analyzing a piece of data to determine that it has not been tampered with. In 
general, two main classes of objects are of interest. The first class concerns the subject of program image certification. 
The second dass generalizes the process and applies the concept to a variety of data otajects. The characteristics of 
the CU. namely a tamper-resistant functional unit allow for the construction of general certification methods of artiitrary 
TO data ot^ects< 

FrcNTi an appUcation perspective, the applicfation must be assured of the identity of the CU The process of estab- 
lishing this kiid of trust is refen^ed to as CU validation throughout this doct^ent. CU validation concerr^ the process of 
assuring the application that the CU has riot bieen tampered^^^^ Le. it has riot been replaced with a bogus CU Aft^ 
the process of CU validation, the application can assume that the connect CU is performing the requested cryptographic 
15 services. 

C^tcation of Code Images. For crttfoal applications, there has lorig been a need to validate that an application 
has not been tampered with. Performir^ this validation usually involves a tru^ed load stteystem. A trusted load sub- 
system is the part of the operating system which Is responsil)le for loading a program image into the system memory 
space and. while doing that* validating that the appiicatton has not been tampered with. Mechanisms, such as a check- 
20 sum over the program image, are commonly used for this purpose. In such applications, if the checksum does not 
match the checksum stored by the loader subsystem at application installation time, the load fails and the program 
image is not loaded. 

A trusted foader subsystem cannot &aGt independently frcxn a relationsh^ to the operating system. Trusting ttie 
loade- to validate that the application has not be^ tampered wttti. implies that ttie operating system trusts the loader. 
25 A trusted kernel which is vaTidated at system boot time, usually t>y a i^ece of hardware, buifcis the core of the trust hier- 
archy cm which the application reskies. 

A CU also IncHides fa-mware elements 27 (see Rg. 2) which inpfement the CU runtime, cryptograph^ service mod- 
ules, and potential user level service module that implements security protocols or otfier user level functions. The 
requirements that apply to applfoation certification also apply to tiie firmware. TTnis. firmware nKxJirfes which are loaded 
30 into the CU are accompanied by a f imiware certificate 25 (Fig. 2). 

Certiffoation of G^eral Objects. \AsdkJating a code image to determine the rightful usage of a certif k»te can be gen- 
eralized to validating any object governed t>y a certificate. For example, an Intennet applet, as they are provkied for 
Wodd Wkie Web applk:ation8 through the JAVA programming language, oouti also take advantage of tiie scheme 
desahed herein. Any object to be used or accessed couki be accompanied by a certiffoate. The vaikfation step is very 
35 sonilar to the steps performed by a tn^ed foad subsystem for code images. 

CU Validation, CU valklation describes the process of ensuring ^t the application requesting cryptographic serv- 
ices is assured about the kfentity of the CU. There are several methods which can accomplish this task. e.g, : 

• Challenge the CU. in this methods the application issues a puzzle to the CU that only tiie CU can resolve. The fact 
40 that the CU coukj resolve ttie puzzle is proof of the klentity of tiie CU. 

• The CU prepares the applfoatfon to functfon. In this approach, the applk»tfon is sh^sped to the target system in a 
scrambled form. For example, the binary image couki be encrypted. Only the CU which has the correct decryption 
key can unsaamble the applfoatidn. and hence it is a vaiki CU. 

45 

The second metiKxl has adcfitional applicability for software copyright schemes. Sending ihe applk:ation in 
encrypted form to tiie target side and letting the CU decrypt the program does not only reveal that the CU is a valkf CU, 
but also allows the software manufacturer to send out an applfoation taifored to that particular CU. Le host system. 
Unfortunately, once decrypted the application image is available in the dear and can be copied to other systems wrtfi 
so little or no effort 

The ICF foundation allows for a method which is refenred to as software level touchpoints and wfiich addresses botii 
the CU valkiation aspects of the invention, as well as copyright protection schemes. The concept of software level 
touchpomts is esqslained in greater detail bekw, 

ICF Adnv'nistration Concepts. The ICF model implements a policy scheme in which tfie apprication requests a dass 
55 of sen^lces whk^ ultimately define the fev^ of cryptography allowed in the applfoatfon. The following is a discussion of 
the concepts of policy and dass of servfoe and how the administrative elements SDA. ADA. and NSS, interplay in the 
definition and distritHitfon of policies. 

Polides and Qass of Service. Fig. 4 is a block diagram showing tiie relationship of the adn^nistration elements of 
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the ICR /:e. ADA and SOA. The ICF is a policy driven imptementalion of ayptography. A policy is the formal definition 
of the level of sendee that is granted in form of classes of service. For exanple. in response to a business requirement 
to have a strwg lev^ <^ cryptography for an Email appfication. a security domain authority may create the dass of serv- 
ice -DES ^2m.' ADAS asking for this strong level of cryptography are given the CXDS defined to iovlement tftis policy. 

The security domain authority defined in the ICF adminfetration framework is the element that creates classes of 
sayice from poOdes defined to meet the authorities' security interests and requirements. A COS has a unique identifi- 
cation. /: e a serial numt)er. that fe not to be reused 1:^ this authority, and that has to be und^stood semantically other 
SDAs in a func!k)n of cross-certification. 

A COS 26 provided to the ADA 22 allows ttie ADA to issue appTK^tion certTicates for an application which contains 
the COS. TWs forms a path of access control. An ai^ication must have a certTicaf e to access the method identSied 
the COS. e.g. a cryptographic operattori at a certain 

The other patfi of contnd within the ICF architedure is the path of existence. The COS defined must be propagated 
to the CU to en^e thfe s^vice at a taige^ if the path of access indkates a valid access, the riiiettibds labeled 

by the COS be tfi a present state for the request to be exeoited. ft for exffliif^ 

policy card and that poficy card is rwnowed from the CU. the associated methocte no longer exfet i.e. they are not oper- 
ating. 

Contrd of acc^ and control of existence of a method are fundamental to the ICF architecture and both should 
always be present in any implementation. Removal of the COS from the existence path results in a non-functioning 
method regardless of the access path evaluatfon resuft 

Policy Activation. Policy activation descra^es the order of events which must tBks place for a CU to offer services, 
as defined through the classes of sendee. Be^e an application can ask for a COS via the application certificate, the 
CU must be ^^tivated for this particular COS. The ICF is unique in the concept off policy controlted activation of cryptog- 
raphy 

Oepencfing on the inplem^rtation. the cryptographic unit must be in connection witii a policy card for the COS to 
be (fownloaded firom the policy card. The VPC scenario requires a network connection to tfie NSS to download the COS 
to the CU. While these solutions are technically more or 1^ eqii\mf ent they have a profound inpfication for the trust 
model of the entire framework- A physical policy card based solution reqiires that the CU inplements toucfpoints in 
hardware. The main reas<»i for th^ fe the detachment of control in the physical policy card case. A physfoai policy card 
is not nec^sarily connected to the domain autiiority environment and lesser control over the policy is possiste once it 
is issued. To conpensate for this, hardware touc»poinfs are placed in (tetennintstic focatfons in the tadware. so that a 
poacy card containing ttie touchpoint data can be toaded, but carrot be renoved from the inplementation without a 
decay of the controlled application. 

Af^mware impleti^rtatfon of the toichpoint concept operates in a nuich more dynan^c way with regard to the toca* 
tion and instaflatkm of these toud^nte becatse the actual firmware to be loaded is not known a priori, thus foavkig 
more room for the attacker. To conpensate for this, an on-line element is present, in the form of the NSS. which allows 
for a more dynamic control of the firmware based touchpoint Implem^itation. 

Classes of Service. Fig. 5 is an illusfrati<»i of tiie dass of servrce structure. A dass of sendee (COS) describes pol- 
ides. As <fiscussed above, a poficy is translated into one or more COS structur^^ 

Classes of service are a structure signed by tfie issuing SDA 20. A COS also contains the touchpoint data neces* 
sary to control the touchpoint mechanisms inside the CU. 

• The m^hod field 51 describes the actual method for which the dass of sendee stands. Exanples are cryptographic 
algorithm Idoit^ers. but also any other defined method such as procedures for installation of conponents or exe- 
cution rights for an operation associated with the COS. 

• The constraints field 52 describes attrSxites d tfie metiiod. Examples are the attributes that govern the tse of this 
dass of sendee. e.g. the strengtfi of the keying material used for tfie algoritiim, the length of time this COS is valid, 
or the number of times it can be used. The touchpoint data field describes the toudpoint information needed by 
the CU to be activated for this COS. 

Classes of service can be nested, i.e. a COS can contain as the method part other classes off servfcea Some 
classes of service. In particular the non-cryptographic dasses of servfoe, may not contain touchpoint data. 

Conmiai to all COS structures ts also the concept of a decay pdicy. A COS can be declared to be valid for an 
unbounded lifetime or it may be linked in lifetime. Examples for a fimited lifetime are a link of the COS lifetime to tite 
lifetime of the OS. the application instance, or the context established with the CU, Restarting the OS or application, or 
dosing the CU context would marie the COS as expired and invaTid. Interaction with the NSS to activate the COS woukJ 
then be necessary 

Other events which limit the rtfetime of a COS are counters. e,g, the number off operations allowed by this COS. or 
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even a single operation which is governed by this COS. The latter is a very powerful tool for creating classes of service 
for exactly one interaction, e.g. as wouW be useful for financial transactions. 

Part of the CU implements the decay functionality in which classes of service are processed according to their 
decay policy. When the policy determines it is necessary to disable the COS, any associated functionality ceas^ to 
5 exist The IGF CU is unique in that it offers ayptographic services driven by a dass of service with constraints that do 
expire. 

A special, predefined dass of s^vice. COSO. is used to guard the COS decay functionality. Because the COSO is 
itself siAject to a decay policy. COS processing can be made cease to exist, thus describing the entire CU Ibr any Wnd 
of service. A new activation from the NSS would be required in this case. 
10 Gasses of Service Levels. Classes of service are organized not only by the object they describe, but also by tfie 
^ ^^^on an implementation performs before granting the service levd desatoed by the COS. The preferred 
enixxfiment of the ICF defines six validation levels for a COS. As the levels inaease. tighter validation (and therefore 
control) over the sendee t^ 

Rg. 6 is a block schematic diagram tiiat illustrates the COS level concept. The ICF inplements several levels of 
J5 COS validatfoa These levels of COS validation are examples only. It will be appreciated that otfier levels of validation, 
and combinations thereof, may be provided in practidng the inv^ition herein. They are labeled COS level 0 through 5. 
As tfie level increases, the amount of validation increases. Fig. 6 indudes a counterdockwise drde 61 which shows the 
elements involved in the validation. At the lowest certified level, only the SOA ori^n of the COS is vafidated; while at tiie 
highest certified level, an on-fine connection and authorizatfon to the NSS for each operation Is required. 

• COS Level 0. COS level 0 Is assigned to applications to whidi a certificate is not assigned. Nonetheless, a mini- 
mum level of protection is provided at tfiis level because the COS is signed by the SDA that issued the COS. This 
level is mainly intended fw applications that cannot be changed to pass a certificate to the CU. 

25 . COS Level 1 . COS level 1 validates the COS 10 as H is made available through the appllcatfon certtf icate signed by 



• COS Level 2. COS level 2 adds to the COS level 1 tfie vafidation of tfie application certificate. The certificate is 
required to be issued by the ADA that asl^ the SOA Ibr the COS identified by the COS ID. 

• COS Level 3. COS level 3 adds to the COS level 2 the validation of the appfration 10 issued by the ADA. 

• COS Level 4. COS level 4 adds to COS level 3 the interaction with tfie NSS to validate the COS requested by the 
applteation. 

3S 

• COS Level 5. COS level 5 further strengthens COS level 4 by interacting with the NSS on each cryptographic oper- 
ation requested by the application. 

• COS Level 6. COS level 6 adds the requirement of a token, such as a smart card, for any one or more of the interact 
40 actior® set forth for COS Levels 1-5 above. 

Flow of Information. Fig. 7 is a block schematic diagram that illustrates key elements in the administration process. 
Such elements indude the application certificate 28, the dass of sendee 24, 26, and the domain authorities that man- 
age them. Rg. 7 indudes both a high level view of these elements and their flow (as shown by the lines and arrows in 
45 the%ire). 

ICF Software Environment. Fig. 8 is a software architecture overview of the ICF software environment. The ICF 
software architecture describes the layers of libraries and system elements which.are needed to inplement the ICF ele- 
ments on a given host system. The foltowing discussion provides an overview on the main software arohttecfure ele- 
ments: 

so 

• Applications. The applicatfon layer 81 is the area of user written applications and Itoraries which need ayptographic 
senrices. An application may or may not be aware of these senrices. In case the applicatfon is aware, the subsys* 
tem layer 82 below offers a set of programming intet^u:es to the application. CryptograpWcaily unaware applica- 

^ tions do not issue any calls themselves, the undertying subsystem pertbrms these calls on behalf of the appKcatfon. 

• Subsystem Ltoraries and Interfaces. The are subsystems which support cryptographic fundions for aware and una- 
ware applications. These subsystems also provide APIs to tiie applications. Most notable APIs indude ttie Micro- 
son CAP! to the Mforosoft wortd. and the X/Open GSS-APf and GCS-APf for the Unix world. Subsystem libraries 
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typicaHy organize themsetves into application programming interfaces and. shiekJed throi^h the c^erating system, 
a aypto^aphic sennce provider module. 

The subsystem libraries may also hide the security APIs conrqaletely from the application. This allows existing appli- 
catiof^ to take advantage of the solution without being modified. An example is the integratkwi of the security fea- 
tures into trarisport level software subsystems. 

Other elements of thfe layer may fwovide APIs for accessing the CU secure storage and execution facifities. For 
exan^e. a database API such as the ODBC int^ce could be offered along with a data manager module ii^ide 
the CU to provide a tamper resistant database. 

• Operating Systems and Drivers. The <^emting system 83 perfom« two r^imary taste. One is to isolate the subsys- 
tem progiammifig interfaces from the cryptographic service providers. The other task is to provide the necessary 
hardware control through a set of drivers 84 which interface with ihe cryptographic hardware in ibrm of hardware 
drivefs: 

• Cryptographic Unit Subsystem. This layer contains the hardware inplementation and fimiware elements of the 
cryptograpNc f uTKrtior^ 85, The hardware is typically provided in several form fectors. such an PCI caid or a PCM- 
CIA card, to accownodate the different hardware platfomts and performance requirements. The firmware is a set 
of Iftwaries which implement a miao kernel runtime, the ICF functionality, as well as user downloadable software 
modules required by a partfcular appTfcation programming interfece. 

• Adi«restra€on. The adn^ra^ration element 86 is responsible for providing a management framework of the entire 
solution. This inckides. for exanple, middleware compon^tts for administrative functions such as certificate man- 
agem«Tt application class of service management, and downloading of application specif k: extensk>ns to the CU. 

The k^ elements are divided into two groups: host system software and cryptographic unit f k mware Between the 
two major bfocks is the def initton erf a command set which is used to communicate requests from the host system to the 
cryptographic unit ar^J vice versa. Each of the main elements is descrft)ed in more detail below. 

Host System Software. The host system scrftware consists of applkation level programming interfaces, system level 
drivers, ax^ utifrty programs whk:h help in conffguring and managing the subsystem. Thfe portion may kx)k different 
dep^'fig on the target platform and Interfaces selected. 

Subsystem Lftiraries. Application uses the ayptographic unit through one or many APIs. APIs may already exist, 
new ones are b«ng proposed as -standards," yet others need to be devdoped to take advantage of the full capabilities 
of the cryptographic unit An exanple woukl be the ability to downtoad and execute code dynanwcafly in a trusted envi- 
ronment. 

TTie cryptographic unit operates in conjunction witfi a wide range of programming inteifeces. AP Is may also be hki- 
den from the applk»tfon in fomi of subsystem libraries or n^eware layers which mask the crypto^aphic operations. 

Host Driver. The host system nuist integrate the cryptog^aphic unit into tfie operating enviionment From a software 
perspective thfe includes the device drivers and any oonfigi^-ation software needed to install, configure, and manage tfie 
policycard. * 

Management Utilities. Utility software is responsible for installation, management and configuration <rf the crypto- 
grafrfiic unit siteystem. It fe also necessary to provkle utilities for devefoping servfoe modules, and utilities for down- 
loading these modules into the cryptographfo unit. 

Cryplographk; Ur^ Command Set. The host sy^em software communicates witfi ttie cryptographic unit through a 
set of requests^ Examples for requests arethedownloadof a service library or the encryption of a data buffer. To sup- 
port multiple f^tforms with the same cryptographic unit the command set should be the same and have the same for- 
mat for all target platfonns. The main ben^it fe a single inplementatfon of the cryptographs unit software layers. 

The conmiand set itself can be divMed into main categories. The first category offers conwiands which map to the 
available fwictionality of the cryptographic ur^t such as the executfon of a hash algoritfim. The second category con- 
cerns commands between the host software and the sendee layer software inskie the itnti. The content of these com- 
mancfe fe largely wiknown to the firmware and they are routed to the appropriate servtee l^er. 

ICF Applfeation Programming Interfaces. The ICF introduces the ooncefrt of polfoy *iven ayptography Applfeatfon 
programming Interfaces alfow to select the desired servrces based on tfie application certiffcate granted by the ADA. 
Thfe fe in contrast to tfie cwrenfly available cryptoyaphk: programming interfaces. Most of ttie curreit cryptographic 
APIs are built around tfie concept of a cryptographk: context Applications establish tftis context before they can us any 
cryptographic service. No linkage fe done between ttie application and tfie dass of service offered by tfie CU. For exam- 
pie. the Miaosoft CryptoAPI. offers a programming interface which aflows tfie user to select ttie cryptographk; senrtce 
provkf er (CSP) type and load tfie software module into tfie system. Thereafter, an afplication can make calte to tfie CSP 
and use Its sendees. There are, however, no metfiocfe to distinguish ciyptograpl^c functions based on what ttie appli- 
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cation is doing. 

Fig. 9 aiustrates the methods available to pass certificates 90 to the service provider 91 responsrt^e for executing 
the requested functions- There are several methods for making the certificate available to the cryptographic unit. e,g.: 

• Certificate passed in each call. The certificate can be passed in each call to the CSR This scheme allows for an 
application which may pass more than one certificate or the task to be a«^ For example, if an application 
IS altowed to use strong encryption for financial transactions and at the same less strong encryption for E-maif func- 
tionality, that application can select dynamically the level of cryptography by passing the corresponding certificate. 

• Certificate passed at initialization time. The certificate can also be passed when the link to the CSP is established 
An application using multiple certificates could establish multiple contexts, one for each certificate, and use the 
appropriate one in the cryptographic function calls- 



• Certificate in^icitly available. The certificate is transparent to the application and available to the cnrptogri^ic lay- 
ers. For example, ttie application passes Hs name which is used to index into a registry that omtains the certificate 
for this application. 

A« of these methocfe rest on tfie assumptfon that there is a tight binding between the application and the certificate 
ThK concept (s referred to as application certification throughout this document As discussed below, the CU plays a 
critical fole in establishing this tight binding. 

ICF Cryptographic Unit. At the core of the ICF framework is the CU. An inp{ementati(m <rf the CU provides a set of 
services t o the ho st system."mese servfoes include ayptograf^ic functions but also other functions, such as storing 
sensifive infbmiation that take advantage of the tamper resistant characteristics of the CU. The fottowing three broad 
categones of servfoes are offered fciy the CU: 

• Cryptographfc functions. The main purpose of the CU is to provide crypto^aphic functions. The unit hosts hard- 
ware and software to canies out the defined cryptographic algorithms, ft also hosts hardware and software which 
enforces a certain cryptographic policy, 

• Secure storage. Secure storage allows tiie CU to store information In a secure nwiner inside the CU. This fecility 
IS primanly used for the storage of keying material inside the CU. Ova- twne. application and subsystem layers may 
also take advantage of tfvs facility by storing other non^ecurity related material kiside the CU 

• Secure execution. The CU allows for tiie execution of code in the secure and tanper-resistant environment of tfiat 
unit. Appbcati'ons and siAjsystem layers may take advantage of this facility to implement a portion of their functfon- 
ality. such as security protocol handlers, in tNs secure environment. 

ICF Cryptography Unit • Hardware Bq. 10 fe a bfock schematic diagram that illustrates an exemplary archrtecture 
of tfie CU Rg. 10 does not refer to a particular physk^l iirpfementation. but rather shows the main elements needed 
ir«ide the CU to inplement the three broad categories of functionality outiined above. There are several conwonents 
which form the CU: 

• Central Processing Unit. The CPU 1 0 1 is the heart of the unit oontroHIng a» information f tow. Modules downfoaded 
for secure execution are executed by the CPU 

• Storage Elements. The CU 14 needs several storage elements. The Flash memory 102 is the storage area for pro- 
grams and nonvolatile data stored in the CU The ROM storage 103 hosts the bootstrap code which executes on 
reset of the CU. The RAM storage 104 hold tfie volatile data of tfie CU 

• Cryplographte ASIC 105 and Random Number Generator 106. These two elements patorm the basic operation 
operations for tfie cryptographic functions offered by tfie CU For inplementations which provide touchpoints in 
hardware. ICF touchpoint logic for enabling tfiese functions in tfie presence of a policy card can be found In tfiese 
elements. 

• Bus Logic. The Bus togk: 107 intei^ces the unit with various other inteifeces to the host system. Two main chan- 
nels exits towards tfie host system 1 08. The first channel, ie. tfie control channel, is used for commands and status 
messages between tfie calling system and tfie CU The data channel canies out tfie actual data transfer 
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ICF CnjptoBrapWc Unit Rr mwara Fig. 1i is a block schematic diagram of the cryptogfaphic unit f irmware. TTie CU 
aiaa^'^l " 'nsi^e the ayptographic unH 14. There is a core runtime module 1 13 which 

controls the overall operation of the unit kernel services layers 112 which implement security policies and control 
access to the cryptographc functions, and service library modules 1 1 1 which closely interact with the hosts system 
applicatons to iirpleinent application specHic security services and policies. 

The fimmare conponenls can be tfivided among a sharp line wWch is called the taist boundary 1 15. Below the 
tnist boundary, the CU core runtme and the actual hardware can be found. Above the trust boundary, the CU runtime 
managmg the entffe and ipper level service modules can be found. 

CUCore Runtime. The CU core luniime impiefflents the low level services wKch shield the underlying hardware. 
«ateo offeis s«wes to the support layers to manage the resources offered by the CU. e.g. memo.y objects for code 
"^^^ ™« CU core runtime is responsible for tfie COS processing. Each operation requested by the upper 

l^s Is accompanied by a COS identifier. The COS decay poRcy is implemented below this boundary. The CU^ 
runtme prrtectnn rests on the follovwng fey mechf^ 

• ^ '^^ implemented in ROM storage. Benefiting from the tamper resistant nature 
of the CU. this code cannot be manipulated nor bypassed, "rhe ROM is mapped info the CU processor address 
T^^. "^^^'^ ^ haidware intenupt vectois such that any reset attempt forces execution to be inside 
the ROM code boundaries. The ROM code runs at the highest privilege level of the CU processor. 

• ^ ^ processor is required to implement at least two privOege levels. Memory ot>iects 
aloratod at the Ngher pnwlege level cannot be accessed by code omning at a lower privilege level. This boundary 
« enforced ly the CU processor hanJware and cannot by bypassed under any circumstances. 

• Perasfent Storage. The CU core runtime requires a cerlain amount of nonvolatile storage allocated at the highest 

pnvilege level only accessible to the ROM code. This storage IS used for the COS processing and 
piocessing. as described in greater detail below. 

AH code introduced above the tmst boundary is subject to touchpoint processing. The concept of louchpoint 
proMssi ng IS discussed in more detail betow. It is importart to note that code above ceases to fu^ 
locations are not resolved by the core runtime durHige)»cution of this code. 

CU Runtime Services. The CU run^ 

nanage and organza the card. It resides directly on top of the CU core runtime. TWs runtime may be thought of as a 

!lSZ!ll£?4l!f^ l*^" f ™® is the only place which drives the cryptographic 
functions availatjie for «ie higher level servfce moAiles. The foBowing basic capabili^ 

• to the nature of the unit, some software modules toaded into the CU need to be vafidated 
b^ they can be toaded and executed. At toad time the loader toads the code image and, if required, validates 
Biesignatwe of these modules. The secure loader is part the Iwnel code and part of the CUo^^ The 
Kernel code Itself is loaded and vaTidated by the CU core runtbne module. 

• Memory Management The menwry manager of the miaohernel is responsible fbra^ 

man Storage. Memory can be aBocated at the different ring levels to ensure piotectfon between ttte memory areas. 

• TaskBig. The task handler provides the basic mechanisms for running mdtiple threads 0^ Incoming 
requests m^ trigger the start of a new task or are simply queued for an existing task to serve. 

• Internal Message Radlify. If itisdesired lhatthe toaded modulesneed to communicate with eacholher. somebasic 
torm of inter task communication must t)e provided. 

• Crypto Paging. Crypto paging altows the memory manager to allocate storage outside the cryptographic unit 
boundary and store pages in encrypted form. This facility is needed if the amount of storage needed inside the unit 
exceeds what is availabla 

• Access to internal Resources. Most of the other components, such as the cryptographic haitlware on the chsx are 
accessed through routines that are part of the micro kernel. 

• External Interfaces. The cryptographic unit interfaces with the host system through this component, which is the 
entry pant for an external requests. The requests are passed according to the defined command set are decode 
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and passed along to the appropriate unit tor executroa Thfe layer may be dependent on the type of host system 
bus architecture. 

CU Services. This set of libraries runs at the least privileged protection level. This level hosts libiaries which could 
implement senrfces for a given programming interface, such as the ICF Envelope APIs, cryptographic APIs, such as the 
Microsoft Crypto API or the XWpen GCS API. or any other APIs as needed to offer an abstraction for secure storage 
sewre execution, or downloading facilities. Commands exchanged between the host system and this layer are defined 
by the implementor of this layer. 

The service libraries layer also offer the possibility of allowing an application to execute some portion of itseH in a 
seajre and trusted environment. This fadlity could be used to inplement copyright schemes, or special functionality 
ai^ as nsk evaluation modules «orf«andal appTications. The progfamming interfaces are application dependent The 
host i^em driver passes the infbrmation between and the application an the service libraries as messages. 
A 0* Virtual CPU: Rg. 12 is a block schematic diagram that illustrates the concept of a vvtuai CPU. 

Another way to look at the f imiware structure discussed above is to combine the fewer level firmware found in the CU 
core runtime and toe underlying hardware into a virtual CPU executing under the constraints inptemented by this com- 

♦K' V^c ^ ^ ^ processor capable of executing instmctions under the control of a policy. Part of 

this ICF CPU IS concerned with the COS evaluation and the resulting toucfpoint resolution process. Looking at the 
coml)ination of the firmware and hardware elements as a joint unit allows a better desopticm of the trust model and 
evaluation of a hardware / finnware combination against it Once this component is validated, analysis of any module 
loaded and executed on top does not have to be evaluated with all the lower ta^^ 
memory protection intermixed. 

Any phy^cal processor model / ROM combination which can implement the protection mechanisms outlined above 
IS therefore capable of being contoured as a wrtual CPU, as may be required by the ICF CU architectura Any module 
written for su^ an ICF CPU can run on any ICF CPU that passes the strong security requirements. 

Softvwe Conponent Certification Process. Software conpone^ 
IS a binding between the a«>lication image and the ap^ication certffk»te issued by the ADA. It also includes 
firmware conponenfs and firmware certrficate issued by the SDA. 

The process of software conponent certification can be described in two distinct stages. They are the installation 
stage and the execution stage. Whenever the term application is used in the following text, it shall also include the 
f mnware components. The following is a brief description of the certification process stages. 

• Installation stage. The installatfon stage desafees the steps necessary to introduce the application and the accom- 
panying certif icate to the CU. 

• Execution stage. The validat<»i stage descrtoes the steps taken to validate the applications identity based on the 
certificate passed atong with the validation request After successful validation the apptication enters the execution 
stage. At any time during this stage, the CU can issue a validatiGn request to revalidate the application's claim. 

Installation Stage, Fig. 13 is a block schematic diagram that shows the software conponoit certification jyocess 
during the iretaHation stage. Certified Applications are introduced to the host system at the application installation 
stage A cerlffied ajplication consists of the afplicatfon image 29. i.e. the code file, and the certificate 28 Issued by the 
application dcxnain authority. The result of the installatfon stage is an application aed^itiai 1 30 which uniquely denotes 
the application, the CU. and the vaTKi classes <rf sen/foes. This result is referred to herein as an application credential. 

The puipose of the install process is to introduce the application 29 to the CU 14. A special utility program, the 
install program 135. is called to carry out the necessary work. The main task of this utility perform is to pass a reference 
to the program image and the applicatfon certificate to the CU. TTie CU upon receiving tfie request for installation uses 
Its host system memory access capabilities to compute a hash value from the program image. 

The application certificate contains, among otha- information.the application ID 137 and the dass of service 136 
defined for this application. Using these two elements of infomiation. the CU produces a aedemial which identifies the 
application, eg, through a name, the hash value of the applk:ation image, and the dass of service defined for the appli- 
caton. 

The aedential is then signed 138 by the CU and stored in focal non-volatile memory inside the CU. If desired the 
aedential couW also be exported to an external area Because the aedentials are only useful to the CU that generated 
thenr it only needs to be ensured that the aedentials have not been tanpered with while aitside the CU boundaries. 

Execution Stage, Rg. 14 is a bkxk schematic diagram that shows the software component certificatfon process 
dunng the execution stage. In tiie execution stage, an applicatfon 29 is loaded by the operating syst m into the memory 
system and starts execution. At some point in the applfoation execution,, the application requests ayptogrephic serv- 
ices. Normally, the first step is to establish a context with the CU An application passes the application oertiffoate 28 
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issued by the ADA to the CU 14 when it estat)lishes a logical association. e.g. a cryptographic context 

Upon receiving tiie request to establish an association, the CU validate the identityof the application based on the 
certrtirate passed. Through the operating system components, the CU has access to the application image and is 
ttwefore aUe to compute the signature of the application. Por example, using the DMAcapabTrty and the krKMledge 
of the memonr^ range of the application within the memory system, the CU can compute a hash value. 

After validating the oonrectness of the certificate, the CU uses the certificate to locate the application credential 130 
coiT^ndtng to the certificate. The credential contains, among other infbnnation, the confuted signature 138 of the 
wreation omge from the installation process described in the previous subsection. If the values matdi. two inrortant 
factecan be deduced. F«t the applicalion's identity is established because the computed signature over this image 
imte^ theoomputed signature at installation time. Second, the application has not been fanpered with since the 
installation stage. 

^ application can issue cEdls tothe CU requesfingcryptogiaphicaperaiions. At any 
on. thft CU may decide to execute this validation process again. The options range from vsriidatirig on a p«i- 
odic basis to validating upon each request. 

Rom an operating system perspective, no changes to the loader and the operating system are required to incle- 
ment tnis schema The only requirements needed are the ability to access the memory image of an object Implemen- 
tations may however decide to invoke the CU at appTtcation load time to perform the validation step. 

Firmware certification is not fundamentally different from application level 
caWxatioa Both sterethe ot»ecth«of estabBshinga ti^ 

difference that (an be seen Is that the lower Iwel firmware objects are certified by the SDA rather than the ADA. High 
aH^^ pntocd modules which are downloaded to the CU, are certified by the ADA 

Another difference is that any firmware module downloadad into the CU. whether a user written high level modirfe 

or vendor supplied lower level module, is subject to the touchpointing process. This proce^ Is optionat fbr application 

obie^ outside the CU boundary. The touchpointing concept is described in greater detail below 
C«1iti«ti<»ofGaneralObjeets.Theschemedescra)edoithepr^ 

not onhr code linages but also any Wnd of data object which could make use of ft^ 

example, the operating system itself, subsystem libraries, and static configuration infbrmation oouM be protected f^om 
unaulhonzed mocfifications or replacemeif Ijy this scheme. 

^ Touchpoinls. Rg. 15 iOustiates software level touchpointe. ICF Software touchpointe are areas of 
^^!l!a"?^® **** * ^ system environment una prepiocessed. One example of a software touch- 
part « that of instruction sequences in a code image i^ 

unit of the processor cannot decoded them successfully. SimHaily. there could be date areas which have been aiterad 
in a way that the wig^ data is not accessible. 

J' software toucf^rt is charact^ized by a starting address within the address range 1^ andthe 
°L!II® ^°!f^ <^«sses of software touchpdnts. Data level toucfpoints describe an area 

insideacfatoobiectftofurlherirtionmtionabouttheT^^ A 
separate date area deecra»8 these touchpoinls outside of the data ol^ect. 

Instruction level toiK:hpaints descrSw touchpoinfs inside an instruction stream. There are two sub ctesses. The f &st 
ajOcla« descrbes instruction level fouctvoints similar to their data level counterparts. In this case, an area in the 
instrucfcon stream is replaced by the touchpoint infbnnation. The second subclass describes instruction level touch- 
pomte tfiat have a sfructure. A structu^ 

touctvomt area. All these types of toud^nte are described in more detail below 

JlSlf^^?**^"^ ^® instruction level touchpoinls. There are two type of instniction level 

touchponls. Thefrsttype 160 implements an instruction level touchpoint as a date area intheinstmction stream which 
h^ be replaced by a scian«led version. No further information is available about the touchpoint at the location itself 
7hesecondtype161 'mpiements the touchpoirt with a distinct instnicfion at the beginning and an instnicBon at ^ 

^^a^'*^ distinguish the two touchpoint areas, the first type of touchpoint is referred to herein as an 
unslrurtured touchpomt. white the second type of a touchpoirt is relen-ed to herein as a structured touchpoint 

Mechanwnsfbr Inplementing Instruction Level Touchpoinls. This discussion concerns the implementetion aspects 
Of software level touclpoints. Depending upon the processor used and ttie hardware support available, touduoinfs can 
be implemented m a variety of ways. Common to all inptemenlations are Ihe following aspecte. 

* Touchpoint Resolving a touchpoint can be done in differert ways. For exanple. a tp.stert and 

tp.erid wstniction oouid demarcate a touchpoirt area. The infomiation in between is the touchpoirt data to be 
frarBlbrmed to Hie onginal instruction sequence. In the case of an instruction level touchpoirt the date in between 
are insfmctions. The demarcation instmction could trap to the CU to resolve the touchpoirt area and put it back into 
ptece again after the instniction sequence has been executed. By iWs. it ensures that with the exception of oper- 
abng system exceptions, no other code can be executed which could have access to tiie touchpoirt area 
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AJternalively. one oouW irnplement h\s touchpoint decoding function inside the instruction fetch unit of a CPU. A 
policy register could store the necessary decoding key f r this application on context switch. Benefits of this 
approach include the transparency of the TP. combined with the benefit of making the code unusable for another 
system. This alternative is discussed more in connection with the discussion betow of host system support fbr soft- 
ware level touchpoints. 

Resohwig a toucfpoint can be done in a way that the touclpointed area is uses a mechanism for ensuring only the 
recipient, i.e. the one which can remove the toudpotnt permanently, is the con'ect redpient for this toucrf^'nted 
object. Resolving a touchpoint can also be done in a way that the touchpoint stays in place and is resolved only fbr 
the duration of ihe usage of the touchpoint area This approach is used to inplement the existence criteria of meth- 
ods inside the CU, It is critical to leave the touchpoint areas permanently in place. 

• Setecb'ng what to touchpoint, A touc^ipoint replaces a sequence of insfructions. The inplementation must provide 
ah ©caxidbn object in which the original instructions are to be executed. The sequence of instructions should be 
executed atomicalfy. The sequence of Instructfons itself has to satisfy certain criteria. For exanple, branches out- 
side of or into a touchpoint area reqpiire substantial siqjport from the processor to detect when someone is inside 
a touchpoint area. However, for strengthenir^ the mechanism, this afternative is worthwhile to pursue. 

There can be a very few or many toudpoint areas in a code object. From the set of possible touchpoinfs. an inple- 
mentation can select at runtime a random set of locations to touchpoint. Also, to strer^en the touchpomt concept 
further, the set can be modified dynamfcally. /.e toucrfpoints are added and removed randomly from the set. This 
defeats an attack in which one could tocate the toucfpoint areas and over time detemim the ori^nal instruction 
sequence. 

• Detecting a touchpoint. Detecting a touchpointed area requires a mechanfem which alfows the processor to detect 
tf^ start and the end of such an area. For fouchpdnt areas that contain branches, ea^ 

with such an indication. The processor's trap capabiiitlee can be used to implement any of these mechanisms. The 
range goes from using a software InfenrMpt instructroa over Htegal operation codes to force an execution, to dedi- 
cated instructions such as the tpjstart and tp^end instruction mentioned above. 

Data Level Touclipoinis. As with the ims^cfured instruction level toudpoint any kind of constant data can be pro- 
tected bjf this scheme If the processor supports a data brealpoint mechanism, these areas can be located during the 
execution and resolved in a similar manner as the instruction level touchpo»its. 

CU Validation Process. Apf^ications must be assured about the correctness <rf the CU The otsjective is to avoid the 
scenario in which someone redirects the applfeation requests to a different cryptographic function. The CU validatfon 
process desafces the steps taken to assure the applicatfon about the iderrtify of the CU. The validation process 
desafoed in this chapter uses the software lev^ toudpoints as the main concept used. CU validation can be described 
in three district stages: 

• Manufacturing Stage, The manufacturing stage descrfees the steps that must be taken at the application manufec- 
twer skie to aeate an application having the software level touchpoint infcwmation Incoporated thwein. 

• installation stage. The installatfon ^ge desaSses the steps necessary to introduce the applicatfon and the accom- 
panying certiffcate to the CU. Depending on the type of insfallirtton. the software level toudpoints may be removed 
at this stage or left intact within the application image to be resolved at execution time. 

• Execution stage. The valklation stage desafoes ihe steps taken to validate the applications identity based on tfie 
certif icate passed along with the validation request. After successful validatiw, tfie application enters the ewcution 
stage. At any time during this stage, the CU can issue a validation request to revalkfete the application's daim. In 
addition to these appScation certification steps, the software level touchpoints installed in the applicatfon must be 
removed or transformed dynamfoaBy as they are encountered by the host system processor. TOs is only the case 
if they have not been removed during the installation stage. 

The CU valuation process outiined below allows for additional benefits tiiat go beyond the main goal of CU valWa- 
tion. From a software manufacturers perspective, issues concerning copyright protedion are t>ecomlng Increasingly 
aitical in a networi< worid. A software manufacturer ttterefore wouW like to be assured that the software shipped to a 
customer is not copied to another system. The range of requirements can range from ensuring tfiat the software is 
loaded to only a valfo group of authorized systems to customizing the software fbr exactiy one system. 

Manufacturing Stage. Fig. 17 is a block schematfo diagram showing tiie manufacturing stage. In tfie manufacturing 
stage. Uie appOcation 29a is produced by tfie applicatfon manufacturer 170^ The objectives are to build an applfoation 
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which be taaored for the particular group of target systems or a single target system TTie target system is identrtted 
bytheCUinstaeedinit 

The application manufacturer first develops the application. This is the executable version of the appTtcation for the 
target host system platform. Before the application can be shipped to the target host system, the customize step 1 71 
installs the software level touchpoinls. After the installation, the appfk:ati(»i 29 can be ^pped. The astomize conpo- 
nent shown in Rg. 1 7 is responsible for ir^Kng the toucJpoints in the applicatkwi image. 

The ADA 22 is the domain authaity in which the application mamifacturer resides. The ADA is granted a dass of 
sendees by the SOA 20 which define the functfon used to insian the toucTpoints into the application imaga 

One point d the toucJvoN tfistailafon Is to produce a fet of 
code image. In the case of ui^tructured instmction level foucf^nts. th« information is needed to locate the touch- 
P^"^ sfructured instruction level tcHJChpoints. this i^ 

tions concerning exactly where a toucf^xwit could be piaced and what the length of such as sequence should be. 

Fcff unsfifucturedtb^ 
tenceTechn^ 

Restncbons tndude that tojchpoints should, for example, not cross procedw^e bouixlaries. or overlay rtnye than one 
basic fajock of instrurtions. The restricti<»TS depend on the nature of the hardware level s^Dport for sfructured touch- 
points. Some of these aspects are disctssed ^sewhere ha^ein. 

/^the end of the maruifacturing stage, there Is an application image augmented with software level toudpoints 
1 72 The touchpotnts were put frrto the wnage In a r^htful way because the COS which enables the (Rations inskie 
the CU for the customize conponent was granted thfe right by certification from the SOA to the application manufacfairer 
ADA. Ths process, so far. does not involve information about the target system. Any installaton which has the capabil- 
ities to reverse the toucfpoint information Install process can derive a working appOcation. 

A further taBwing down of the target system requires additional knowledge about tKs systaa Because this Intro- 
duces a tighter dependency between the manufacturer and the target recipient, a Ngher effort e necessary on the 
adnmstration skle. 

Inst^fation Staga Rg, 18 is a block schematic diagram showing the instaflation stage. The ir^Katfon stage 
descrfoes the steps taten at the target site, /.e the host system and a speai'tc CU 14 are necessary to prepare the 
applcation 29 for use on thfe system. Again, there are several objectives. The fffst ol^'ective is to ensure that an appli- 
^on IS assured about the imegrity of the CU. This assurance is achieved tyth^ 

the necessary COS to process tfie applkstkm Image Is able to successfully transfomi this im^e into a i^e one. The 
second elective fe to ensure that once an appficafion is Installed on the ^ 
mid cannot be copied to anoth«* system. 

The inst^ler conponoit 1 80 is respCHTSft3le for Installing the application in the targ^ system. As a part of the install 
process, the appGcatfon's aedential 28 which descrtoes the COS 26 available to the applk»tlon is created. The <fataiis 
of tWs process are descrfoed n greater detail abova The other part of the install process preforms tfie st^ necessary 
to prove that this Is a vaia CU and to build an ^ 
the CU that was used tiy the install process. 

The SOA20 grants the ADA 22 the set of COS26. The ADA grants the w^fcatiwi rig 
card 12 contair^ the valid COS for the ADA and the COS for the installer as ft was gmrt^^ 

manufacturer. The Installatfon component can therefore only process the touchpdnts in the apbiics^ image if ft was 
granted the COS to do sa 

Toudpointecanintheory be removed at the Instaltetion stage. However, removing them ftxjm the application brrage 
at this Stage has two consequences. Rrst the applicatfon has only a one time assurance that the CU is a valid CU at 
installation feme. After the ranoval of toucfpoints another CU could be in^alled along wfth another polk:y card or be 
bypassed when the ^cation requests cryptographfo servfces. Second, wfthout the touchpoints the application is in 
the dear and can be copied and executed on any other system. To prevent these scenarios, the touchpoint should be 
removed as late as possible In the executfon cyde. 

Executfon Stage. F^. t9 Is a block schOTatic diagram of the executfon stage. In the exeojtion stage, the applica- 
tion nrns on the ho^ system. The operating system loaier 1 90 transfomis the application file image into the executat^e 
memory image. One part of the process concerns the requirement of vaTidating that the application has not been tam- 
pered wHh since installation time and r^htfully requests a certain dass of servfoa The steps taken to ensure this have 
been desaibed above In connecffon wfth the discussfon of applk»tfonoerti^ addl- 
tional steps are required. r-- . 

At.apprication toad time two main ot^ectives need to be addressed. The first ot^ective fe to validate the CU. This 
task is acoonplfehed tf the CU is able to resdve the software toudpoints from the application. For. exan^e if the CU 
is able to compute the original signature of tfie applicatfon wfthout the touchpo&ite. ft proved that ft can successfully 
rernove them and is therefore a valid CU because ft was granted f^^ 

tive is to resoVe the touchpoints. The CU is responsfole for removUig the touchpoints before th application portion that 



16 



1 



EP0 843 249A1 

contains th^ Is executed. 

The simplest case is for the CU to remove the touchpoints from the application code image. The file image of the 
program would still contain the touchpoints and stays useless if copHed to another system. The memory portion e how- 
ev©- in the dear and oouW l>e copied if a malicious user would write a coq^ program wtiich constructs the file image 
5 from the memory image. Such a task requires some skillset and knowledge of tfie underlying operating system, but is 
notNipotssiUe. 

Another approach is to leave the touclpoints in place and resolve them as they are encountered. This approach 
relies on some hardware support to detect the touchpoints. This is descrtoed further in connection with the discussion 
on hardware support for software level touctpoints herein. 
10 Tailoring to a unique CU. The process desaibed so far does not establish a close relation between the software 
manufacti^er^ software con^onent and the target system identified by the CU installed in it The b«iefit of the rather 
loose coupling permits the manufacturer to produce an applicatton wftich can be installed on any system that has the 
capability to process the touchpoints installed inskie the a«3lication. No further knowledge about the target system is 
rec^lred. 

IS If a more tight binding is desired, the applfcation manufacturer needs to faifor the appOcatbn conponent to the tar- 
get system CU. This could be done, for ©ample, by creating a unique COS which is shared between tfie manufacturer's 
ADA and the SDA, The SDA installs the unique COS on the policy card when it is customized for the target sy^em CU 
and shares that COS with the ADA of the appTication manufacturer. Only the installation utility on the target system 
which is granted that unique COS can successfully install the software the target system. 
20 Firmware Touchpoint Support in the Cryptogrsphk: Unit, Rg. 20 illustrates the princpfe of Oasses of Service, 
touchpoWs, and envetopes. Frmware level touchpoints are touchpdnts ffistafled In a firmware modute whfch reskles 
inside the CU. As such, they rrwst be controlled by the ICF CPU descrtoed in above. There are three basic btocks of 
functionality which the ICF CPU mus« provide to handle f imware level touchpoints, 
Rrmware toichpoint processmg involves three basic components if the ICF CPU: 
2S The fifiBt bkx* Is envelope handling 200. Policy activation, ile the process of sending the appropriate informatfon 
to the CU to activate a certain dass of servk^e. is communicated between the NSS and the ICF CPU via envetopes 20 1 
as they are desaibed in the ICF architecture. Before any further processing of these envetopes takes place, their ori^n 
and vafidity n^ds to be verified. 

The valkfated and authenticated <»ntent of the envetope is passed on to the second conponent which is the COS 
30 engine 202. The COS engine can be seen as the heart of managing the classes of servtee installed on this CU. Each 
r equest fty a sendee assocfated witfi a COS iilreaed to this engine and evaluated for access control to this resource. 
In askmm. the COS engine also maurtains a heartbeat fUnctton which allows implementation of COS decay. Per i- 
odfeally. the COS ^ne analyzes each COS stored and veiffies that the boundary conditions for this COS are still true. 
The boundary condt*c»TS are also evaluated for each req^e^ if the COS attribute specifies it For example, a COS which 
3S specifies that only a certain number of c^ratfons are allowed invokes the engine evaluation mechanism on each 
request and decrement a counter. 

The thiid b^c comporont is TP Resolutfon 203, The TP resolution btock is responsible for handfing the resdutfon 
of toucfpoints 204 as th^ are encountered by the executing f imiwara Throug^t one of the medianmms outlined earlier, 
control of executfon trarefers to tt»s component and the instn^rtfons whfch are masked by me toiK*¥)oint are executed 
40 within the trust boundary 205 established by the ICF CPU. Once the COS engine determines that a COS is no tonger 
accessibfe. the COS is marked invalid and the TP resdutfon process does not function for this COS. As a resuft the 
firmware can no fonger be used. 

Host System Harc^e Support for SW Touchpoints. Fig. 21 ifiustrates the memory hierarchy with respect to the 
software touchpoint resolution. Software level touchpoints can take advantage of hardware oipport from tiie host sys- 
4$ tern CPU. A key aspect of this embodiment of tiie invention brings the resolutfon process of touchpoints doser to the 
host system processor execution elments. By moving ttie resdutfon process dose to the processor 210, eg. the 
cache siijsystem 21 1 , no toud^'nt areas in the dear are in the main memory system 212 or storage elements 213 
at a tower level in the nremory hierarchy. 

In this embodiment of the invention, there are two main approaches for resdving software level touchpoints. In tfie 
so first approach, the host processor generates an exceptfon upon detection of a software touchpdnt which invokes the 
CU to resdve the software touchpdnt. The second approach is fairly similar, except that is uses the host system 
processing el^nents for the actual operations. Botii approaches can further be subdivided according to structured ver- 
sus unstructured software touchpdnt 

The Trap to CU Approach for structured Instrudfon Level Touchpdnts. Ftg. 22 shows a host system processor 
55 fetching instrudfons from the memory code image 221 of an application which has structured instrudion level touch- 
points 222 installed. In the trap to CU approach, the host system processor 223 raises an exception when encountedng 
a toud^int start instruction. The exceptfon handler invokes the CU conponent to remove the touchpoint and replace 
the toud^nt data with executable instrudions. The host system processor then oontiruies to execute the application. 
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Upon detecting the touchpoint end instnjction. the host system processor traps again and the CU can transform the 
memory rmage back to the touchpoint state. 

The host system processor uses the tp^start instmction to raise an exc^on which cause the CU to l>e invoked. 
The CU is then givan the knowledge of the memory address range and the memory kxation of the touchpoint to trans- 
form the touchpoint body into an insfruction sequence which can t>e executed l)y the host syston processor. Control 
then returns baxk to the host system processor. Once the touchpoint is translated in this fai^tion, other application 
instances could potentially access the touchpoint area. It is therefore inportant to implem^it the touchpolnts as a ait- 
ical section in whic*i no applicatfon context switching Is aHowed. Upon end of the touchpoint instruction sequence, the 
fp^end in^ajcti<m causes a trap to the CU which altows the CU to 

Use of Host System Processor Elements for structured Instruction Level Touchpoints. Hg. 23 is a block schematic 
I**"?^? toMCtpcOnt S44)port inside the host system j^ocessc^. THs second apfw^oach 

asswnes that ^^^^ system processor 223 has a built in togic conponent 230 which allows it to the decode ttie touch- 
p<»'nt during instaictidn fetcK Upon eiiopuritwhg a td^^ instructfoa the Hog! systern p^^ 

the toucfpdnt data within the processor's cache 224 and continues the executfon. t4o memory image changes take 
frface. Upon encountering the touchpoint end instrucffon, the cache line 225 is flushed or left future use. To suf^ 
tWs scheme, touchpoints are requred to align on a cache boundary which should be a muHipte of the cache line size. 

l^xwi detecting a tp^start instruction by the ho^ system proc^sor instnjction fetch unit, the tost system frst 
fetches and fh«i transforms one or more cache lin^ that contain the touchpoint area, using the key stored in a host 
system pracescr control register 226. Each appKcatim may have a cfrff^ent tp^reg va^e for resolving the foucf^xjint 
area. The tp_reg value Is part of the COS-TP which was used to install the appficatoi in the host system. The loading 
of the tp_reg contml register at context swrtoh Involves the CU as the keeper of the mfomiafion. The key^reg value couW 

also be mafe part of the appTKarton cortext state, so that it can be kM^ 

CU. 

AFpnoaches for unstructured Ir^truction Level Touchpo&its and Data Level Touchpowifs. Both unstrtwtured instruc- 
tion lev^ toudvotnts and data level toucf^ints are characterized by tfie absence of any meta informatiai about the 
toucfpohits at the foiwfpofrit focatidn rtself. The approach for this class of software touchpdnts can be sdxlivided into 
two steps. Thefirststepconcernsftedetectionof these touchpoints. the second step re^^ 
systan f^ocessor accesses that area. 

To detect a touchpoint area, mechanisms must be put into place in both the software envkonmenf and the hardware 
to propagate the infomiatfon about the locatkm of the touchpoints to the host sy^em processing elements. i=br exam- 
pte. if tie granularity of the touchpoffrt areas is chosen to be on a pafi^ size of 

syi^em. the information ab<ajt the touchpoint focatfon could be communksted tfraigli the p^e tables and translatfon 
look askJe buffers to the ho^ system processor. 

During address translatoi, the host processor can virfiether the address range to be translated contains soft- 
ware touchpoints or not VVhen loading the cache Iffie for execution or ac^ 

processor, th e touctpoint area is r esd ved in the each e subsystem as described above. Sknaar technkiues apply when 
the resolved touchpoint areas are kept in the cadt^ lines and are not accessible in main memory, or the disc images of 
the oti^'eds tfiat contam them. Read only cache lines are simply flushed whenever they are not needed anymore Cache 
fines modified nwst be ftar^med back before they are written back to the main memory sy^em. 

Although the invention is d^ibed herein with reference to the preferred embodiment, one skilled in the art will 
readily appreciate that pther applicatfons may be substituted for those set forth herein %vittiout departing from the apWt 
and scope of the present invention. Accordingly, the invention shouki only be limited by the dakns included below. 

(^afms 

1 . An apparatus for vaTidating that an api^foation (29) r^htful^^ executes a certain class of sendee (26). oonprising: 

an applkatfon domain authority (22) for granting a level of authority in the form off a certif fcate (28) containing 
valid classes of servk:e: and 

mear^ (14) for tightly binding said application to said certificate. 

2. The apparatus of Claim 1. further comprising: 

a cryptographk: unit (14): and 

means (12) for establishing trust between sakl application and said ayptographic uiit wherein said application 
is assured that saki cryptographic unit has not been tampered with. 

3. Theapparatusof either of Claims 1 and 2. further comprising: 



18 



EP0 843 249A1 

a trusted load subsystem (12) for pertbrming application validation; 

means (14) for loading a program image into a system memory space; and while doing that, validating that said 
application has not t>een tanpered with. 

4. The apparatus of Claim 3, wherein said trusted load sut>system further comprises: 

means (27) for using a checksum over a program image; 

wherein the toad faite and said program image is not loaded rf the checksum does not match a check- 
sum stored by a loader subsystem at application installation time. 

5. The apparatus of any of Claims 1 to 4. further comprising: 

means (27> for validating any object governed by a certificata 

6. The apparatus of any of Claims 1 to 5, further comprising: 

means (27) for challenging said cryptographic unit. 

7. Theapparafusofanyofaaims1to6.wherein6aidappricationi^ 

said apparatus further comprising: 

means (30) for preparing said application to function with said cryptographic unit: 
wherein only a ayptographic unit which has a con-ect decryption key can unscramble said application. 

8. The apparatus of any of aaims 1 to 7. further comprising: 

means (26) for creating classes of service with a security domain authority (20) from pdides defined to meet 
said security domain authorities' security interests and requirements, where said dass of service has a unique 
identification that is not reused by said security ctenain authority. 

9. The apparatus of any of aaims 1 to 8, further conprising: 

means (22) for defining dasses of service with said application domain authority, where said dasses of service 
are validated by a security domain authority that has polides defined to meet said security domain authorities* 
security interests and requirements, where said dass of service has a unique kfentifkation that is not reused 
by said security domain authority. 

10. The apparatus of any of Claims 1 to 9, further conprising: 

means (26) for providing a dass of service from said security domain authority (20) to said application ctomain 
authority (22) to allow said application domain authority to issue application certificates (28) fbr an applfoation 
which contains said dass of service; 

wlwein a path of access oontmf is fonnod. 

11. The afvaratus of any of Qaims 1 to 10. wherein an application must have a certificate to access a method identi- 
fied t>y said dass of service. 

12. TheapparatusofanyofClaimsl to 11, further comprising: 

rs (28) for propagating a dass of service to said cr] 
yptographic unit; 

wherein methods labeled by said class of service must be in a present state for a request to be exe- 



means (28) for propagating a dass of service to said cryptographic unit to enable saki dass of service at a tar- 
get ayptographic unit; 



cuted. 



13. The apparatus of any of Claims 1 to 12, wherein both control of access and control of existence of a method must 
always be present to maintain a method defined by sad applicati n in a functioning state. 
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14. THe appamlus of any of Claims 1 to 13. further comprising: 

^SSJ^ ^SS."^ <=ryptographic unit before an application can be granted a dass of senrfce via 

" S(i^^.ss2SLrd;r.^^ 

16. The apparatus <rf any of Claims 1 to 15, further oonprising: 

xsss'cSss'is'iir^ 

17. Tlie apparatus Of any of Cfaatisl to IS. further oonprising: 

* '^'ISSfi^ "^l^?"'^ cryptographic unit (14) to implement touchpoints in ha«fware: 
wnwein said touchpoints are placed in detenrtrtstic tocations in said hardware- and 

maybeanurboundedormaybeoonslrainedbypredetemiinedcriterla. oeaeaareaTODevaw 

22. T»» apparatus ofany of Claims 1 to 21, said class of service further comprising: 

a spedal. predefined class of service thm is used to guard class of senrice decay functi^ 

23. Th9 apparaftis of any of Claims 1 to 22, wherein classes of senice are organized not only by an oWect that ihev 

25, The apparatus of any of Cfeumsl to 24. further conpria^^^ 

adassof ^viceie^that vafidatesa dass of service ID. as ft is made available thKMigh an application certif- 
icate. has been signed by a security domain authority. «»»icwinn cenir 

^ 26. Theapparatusofanyof Claims 1 to 25. further conprising: 

ta^^Jfli? ^^^"t^ "^^^"^ ^ application certificate, where said certificate is required 
service I D from said security domain authorrty. 

ss 27. Theapparatusof any of Claims 1 to 26. fisher comprising: 

adassofservtele^elthatreqdres^^^ 
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28. The apparatus of any of Claims 1 to 27. further conprising; 

a dass of service level that requires interaction wfth a national security server to validate said class of service 
requested by said application. 

29. The apparatus of any of Oalms 1 to 28. further comprising: 

a dass of service level that interacts with said national security server on each operation reauested bv said 
appficafion. ^ j 

30. The apparatus of any of Qaims 1 to 29. further conprising: 

^ dass of service level that requires a token (50) for any one; or cbmbihMoh of , validations and interactbns. 

31. TTie apparatus of any of Claims 1 to 30, wherein said dass of ser^^^ 
tfon. 
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